Once a project is underway, analyzing the project schedule at a point in time, the data date, to verify that completion is on track, and to possibly revise the plan and schedule going forward is a common process. Starting with the established plan and schedule (schedule model), schedule analysis, as of the data date, includes investigating the impact of delay events that have occurred and those that are anticipated to occur. Schedule analysis performed contemporaneously with or before the delay event is prospective. Retrospective analysis performed within the context of a legal proceeding, after the delay event has occurred and impacts are knowable, is forensic schedule analysis.
The Critical Path Method (“CPM”) has been the dominant scheduling paradigm in project management for over fifty years. CPM is based on complex mathematical algorithms. CPM receives as inputs a list of activities required to complete a project, the duration of each activity and a dependency relationship between the activities. CPM stores the information in databases and utilizes inline scheduling engines to carry out schedule calculations in a succession of batch modes.
In the 1960s, CPM began gaining acceptance as a tool to evaluate schedule delay. Unlike Gantt charts, CPM was rule-based and considered the relationships between activities. Analysis of delayed performance could be approached by inserting delay activities in the schedule, and calculating the impact on activity dates, logic sequences, activity total floats, the critical path and the completion of the project. Analysts also realized that possible causes of delay could be inferred by comparing two schedules, or a particular logic chain in two schedules, and studying changes in activity durations, dates and total floats. Such comparisons were useful, even if they did not provide the detail necessary to allocate activity-level variances to specific delay causal events or calculate the effect of activity-level variances on parallel logic chains.
Several methods of forensic schedule analysis exist using CPM. Modeled methods begin either by inserting in the schedule, or extracting from the schedule, activities portraying the impact of unplanned events. The schedule is then recalculated and compared to the before state. Observational methods examine a schedule in comparison with another, with the analyst not changing the schedule or applying the CPM algorithms to calculate an impact scenario. Modeled methods rely on the as-planned schedule, a baseline statused before a specific delay or the as-built schedule. Exemplary modeled methods include Impacted As-Planned (“IAP”), Time Impact Analysis (“TIA”) and Collapsed As-Build (“CAB”). Observational methods infer causes from activity-level variances by comparing the as-planned v. as-built, the as-planned v. an update or two updates. A brief explanation and critique of these schedule analysis methods follows.
First, IAP analysis inserts activities for excusable or compensable delay in the as-planned schedule, and compares the recalculated results (i.e. as-planned plus impacts) to the as-planned, before the insertion(s). The as-planned schedule is the only schedule model necessary to undertake an IAP analysis. Accordingly, IAP requires an as-planned schedule that is validated as reasonable for use as a baseline. If the contractor's original (i.e. source) schedule was unbiased by status or time impacts, was accurate, reflected the contractor's original intent and conformed to the contract, then it could serve as a reasonable baseline. In practice, however, it is rare for a source schedule to be valid for IAP analysis without adjustment or alteration. Complications arise when the analyst is faced with contending, conflicting source summary and detailed schedules, when the source contains thousands of activities, and when the source is available in hard copy only, without disclosing all relationships and total floats. These complications are not unique to IAP as they afflict time impact analysis as well, discussed below. In addition, IAP is disfavored (even with a reasonable as-planned schedule) particularly for compensable delays. Inserting compensable delays and allocating responsibility to the owner for the resulting extension, without considering contractor delay are weak hypotheticals. It ignores what actually happens on the project by failing to consider actual performance by all parties, e.g. the contractor.
Second, TIA analysis is prospective and based on the analysis of delays in real time, before they occur. The all-important predicate for any TIA analysis is for the schedule model to be current with activity actual dates and remaining durations and the plan going forward. Three steps are involved. First, the as-planned schedule is statused through a closing date immediately before occurrence of a delay. Next, the prospective portion of the schedule model is revised to reflect the plan going forward. In the final step, the delay is inserted in the prospective portion of the schedule and the resulting critical path and completion date are compared to those from the second step.
The prospective application of TIA is conditioned upon four predicates. Early submittal and prompt acceptance of a suitable baseline schedule are pivotal. Once formed, the baseline schedule must be regularly statused to a data date and kept current to the right of the data date. Last, but not least, if slippage has occurred by the data date, the causing delays must be modeled so that any dependencies between delays past and to the future of the data date are properly considered. These hurdles are not insignificant, particularly when the baseline is pursued at a Level 3 degree of detail.
When TIA is applied retrospectively, TIA proceeds in windows rather than when delay events occur. For each window, the schedule model is made current, or statused, within the window by using actual activity durations and actualized logic, but not actual dates; and beyond the window, by revising activities and logic to reflect contemporaneous intentions for the plan going forward. Next, time impacts that actually occurred during the window are inserted in the logical sequence and timeframes in which they occurred, and the schedule model is recalculated with the prior window closing date. This ensures that when the next window is evaluated, time impacts that have occurred in the prior windows are modeled and can be considered for serial effect. Lastly, the window is fully statused by introducing actual dates for the activities and actualized logic, at which point the window closing date becomes the data date for the schedule going forward.
When TIA is applied retrospectively, bias can be introduced simply by the choice of the event determining the closing date for a window. Widely-divergent windows compromise the method's ability to properly pinpoint shifts in the critical path(s). Retrospective TIA applications permit concealing an actual critical path shift by cherry-picking windows or choosing longer windows. The choice of windows can affect the outcome of the analysis. However, these flaws in the retrospective application of TIA may be solved with windows at regular intervals rather than immediately before delay events.
Third, CAB analysis is retrospective, based on activity actual dates, durations and logic sequences, including delays. The theoretical application of CAB extracts from as-built activity durations excusable or compensable delays. Next, extracted delays are removed and the collapsed as-built is recalculated. In the final step, the collapsed results are compared to the as-build, before collapsing. The downside is that CAB requires a contemporaneous as-built schedule or one built by the analyst. Contemporaneous as-build schedules may be reliable sources of actual dates and activity date variances, but they seldom provide reliable as-built data as to activity intermittent works, actual logic ties, critical path shits or time impacts, which means that they are rarely usable as is. Adjusting or building a reasonable as-built schedule after the fact is resource intense, and is best approached with due care to avoid shortcomings possibly afflicting the method, such as vulnerability to inadequate or manipulated analysis.
Fourth, observational methods rely on comparisons and serve as methods unto themselves or as a preliminary step to more detailed modeled analyses. In the method of as-planned versus as-built, the as-planned schedule is compared to the as-built schedule to identify differences between the planned and actual progression of the activities, allow the
Criticisms to observational methods run the gamut from lacking scientific precision, to “smoke and mirrors” and questionability as to whether such methods should survive a Daubert review. There seems to be agreement that simply comparing two schedules without CPM calculating impact on the critical path falls short of an analysis.
The foregoing schedule analysis methods suffer due to the shortcomings and limitations of CPM. CPM was developed in the late 1950s as a prospective method for planning and scheduling an entire project, before work was started. CPM did not initially consider updating and making the network schedule current with progress once the project started. In the early 1960s, schedule analysis was introduced using CPM. However, schedule analysis methods then, as now, applied CPM calculations only to the portion of the network right of the data date.
Once actual dates are introduced in the scheduling process, the CPM algorithms cease to function for the portion of the network left of the data date. The CPM calculations go inactive to the past of the data date for two reasons. First, total floats can no longer be calculated using the CPM equation of late finish date (or actual finish) less early finish date (also actual finish). Second, even if total float, in the conventional CPM sense, could be inferred by observation, corrections would have to be made because, for any completed activity, actual dates may not have occurred on the earliest possible actual dates, a necessary condition for CPM to correctly calculate activity as-built total floats.
CPM's inability to calculate total floats in the past (left of the data date) hinders retrospective schedule analysis as the critical path cannot be CPM-calculated for the as-built portion of a schedule (or the as-built schedule for that matter). This retrospective void in CPM, in addition to the shortcomings and limitations discussed supra, is recognized in forensic applications.